Re: UNSAID - two test cases (dawg:unbound, issues#useMentionOp)

>On Wed, Dec 22, 2004 at 05:26:01PM +0000, Andy Seaborne wrote:
>>  >Yes, but SQL for eg. has tri-value logic (true, false and NULL), so you
>>  >can meaningfully apply operators and functions to unbound values (NULL).
>>
>>  It doesn't quite work out that simply.  It's fine for operators and
>>  functions but pattern matching isn't so straight forward.
>>
>>  OPTIONAL (<x> ?p ?o)
>>   (?o ?q <y>)
>>
>>  so ?o may be NULL then we have the (?o ?q <y>) and it needs to handle
>>  ?o = NULL differently.  NULL is different.
>
>Yes, bun in RDF you cant have a triple like (NULL ?q <y>), so that match
>will always fail. Unless I'm missing something.
>
>>  Talking about NULLs, with all it special cases for matching and function
>>  handling, like NULL != NULL, is no different to talking about unbound
>>  variables.  Both need special handling.
>
>There are no special cases. Any arithemtic operation involving NULL is
>NULL, so NULL == NULL is NULL, NULL > 3 is NULL, ...

OK, that is 'weak' 3-valued logic.  Is there any way to write an 
expression whose value is true when its argument is NULL? If not, 
then NULL is just a kind of universal error-mark, and does not really 
change the underlying logic; it just makes everything more 
complicated  and messier to state, and provides no useful 
functionality. In fact it is not really a value in the usual sense at 
all; its really 'below' the real values, and acts as the bottom 
element of a semilattice. All this will do is create confusion when 
we try to define instance, matching etc.; and I can't see that it 
would buy us anything positive to make up for all the complication 
and confusion.

>
>>  >I have said a few times that DAWG I think should come down off the fence
>>  >about tri-value logic.
>>
>>  Do you have a test case where it makes a difference?  I have difficulty
>>  seeing this as other than a difference of linguistic approach, trying to
>>  use the same language for matching and for operators.
>
>Yes,
>
>	SELECT ?foo
>	WHERE [ (?foo :p ?x) ] [ (?foo :q ?y) ]
>	AND ?x != ?y
>
>In a tri-value logic, this will only succeeed if ?x and ?y are bound, I
>think.

There is no way to tell until someone comes up with an exact account 
of what != means. But why would this case differ in a 3-valued logic 
from the way it would be handled in a 2-valued logic? It only has the 
effect you say because the inequality requires its arguments to be 
bound. We can specify this as a constraint on the != operator without 
changing the underlying logic.  (BTW, there are 3-valued logics in 
which NULL=NULL is true.)

>
>>  It seems to me that we have to say what happens with op:numeric-less-than
>>  encounters anything unexpected through the casting rules of F&O extended
>>  for bNodes anyway.
>
>Yes, but what. The Perl/PHP/ECMAScript convention is that
>
>	?x is unbound, ?y = 3
>
>	?x != ?y is true
>	?x > 3 is false (for various reasons)
>
>In SQL they are both NULL, again, I think, My SQL is rusty. e.g:
>
>	$y = 3;
>	if ($x != $y) { print "true\n"; } else { print "false\n"; }
>	if ($x > 3) { print "true\n"; } else { print "false\n"; }
>
>prints
>
>	true
>	false
>
>In PHP and Perl.
>
>In Perl $x > -1 is true (unbound = 0, I guess), in PHP its false.

I would suggest that the simplest way for us to go would be to say 
that if any arguments are unbound, then any operator is false. So if 
?x and ?y are unbound then neither of ?x=?y, ?x!=?y are true.

Notice that we don't need to give these a value in the unbound case: 
all we need to know is that they are not true in this case, so if a 
constraint has them in it, then it fails. Our logic is always 
2-valued, and the values are <true> and <anything other than true>

Pat

>
>- Steve


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes